ping @eparis since you're the only other person in pkg/util/iptables/OWNERS and @dcbw is on vacation right now

/kind bug

/lgtm

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: danwinship, eparis

The full list of commands accepted by this bot can be found here.

The pull request process is described here

The problem also exist in iptables-restore v1.4.21.

[root@k8s-worker-1 vagrant]# iptables-restore --version
iptables-restore v1.4.21

[root@k8s-worker-1 vagrant]# iptables-restore -w5
iptables-restore: invalid option -- '5'

"Real" iptables 1.4.21 doesn't support --version or -w, and kubernetes won't try to use the flag with it.

RHEL ships iptables 1.4.21 plus a lot of backports, including the --version and -w patches. Unfortunately, iptables-restore 1.4.21 doesn't consider it a fatal error to pass an unrecognized flag (like iptables-restore 1.6.2 does); it prints an error about the "5", but it doesn't exit, and it still accepts the "-w". So that's how the bug slipped in to kubernetes; it was tested against the RHEL version of iptables, and the invalid option -- '5' message gets eaten by kubernetes if iptables-restore exits with status 0, and it was still obeying the "-w" part, so from the outside it looked like everything was working correctly.

I changed my OS from CentOS 7 to Fedora 27 now running iptables v1.6.1. It dont get the -w5 error in journalctl, but the rules still not showing in iptables -L, though they are showing up in iptables-save.

Now i get this :

Mar 10 17:45:10 k8s-worker-1 kube-proxy[22884]: E0310 17:45:10.260208   22884 proxier.go:792] Failed to execute iptables-restore for nat: exit status 1 (iptables-restore: line 
Mar 10 17:45:10 k8s-worker-1 kube-proxy[22884]: )

Made an issue here : #61005

Am I the only one that thinks that Red Hat not changing the version number but expecting the new flag to work is somewhat wrong? Or am I misunderstanding?

You could argue that it's wrong, but that's totally separate from this PR (which is needed in order to support the official upstream iptables release). And the "detecting whether iptables-restore supports -w or not" part is working fine anyway. It's the "actually use -w" part that was broken.

This should get whatever tags, milestones, etc, are needed to make sure it ends up in 1.10.x as soon as possible after the .0 freeze ends

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to fejta).

Review the full test history for this PR.

Silence the bot with an /lgtm cancel comment for consistent failures.

[MILESTONENOTIFIER] Milestone Pull Request Labels Incomplete

@danwinship @eparis

Action required: This pull request requires label changes. If the required changes are not made within 3 days, the pull request will be moved out of the v1.10 milestone.

priority: Must specify exactly one of priority/critical-urgent, priority/important-longterm or priority/important-soon.
sig owner: Must specify at least one label prefixed with sig/.

Automatic merge from submit-queue (batch tested with PRs 60978, 60985). If you want to cherry-pick this change to another branch, please follow the instructions here.

Is there any way this could be merged into v1.9 milestone? We upgraded to v1.9.5 in order to fix some other issues, then began encountering this. Please let us know what can be done, thanks!

I am using kops debain stretch image which has iptables 1.6.0 and even after upgrading the cluster to 1.9.7 which has this fix backported the issue still remains. I still see the error in the logs and the services present on the node started crashing with liveness failures.

iptables 1.6.0 does not need this fix. you presumably have a different problem